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Abstract 

This paper presents a new compiler called Poing 
Imperatif. Poing Imperatif extends Faust with com¬ 
mon features from imperative and object oriented 
languages. 

Imperative and object oriented features make it 
easier to start using Faust without having to imme¬ 
diately start thinking in fully functional terms. Fur¬ 
thermore, imperative and object oriented features 
may enable semi-automatic translation of impera¬ 
tive and object oriented code to Faust. 

Performance seems equal to pure Faust code if 
using one of Faust’s own delay operators instead of 
the array functionality provided by Poing Imperatif. 
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1 Introduction 

Poing Imperatif is a new compiler that extends 
Faust with imperative and object oriented fea¬ 
tures. 1 

The input code is either Poing Imperatif code 
(described in this paper), or pure Faust code. 
Pure faust code and Poing Imperatif code 
can be freely mixed. Pure Faust code goes 
through Poing Imperatif unchanged, while Po¬ 
ing Imperatif code is translated to pure Faust 
code. 

1.1 About Faust 

Faust [Orlarey et al., 2004] is a programming 
language developed at the Grame Institute in 
Lyon. Faust is a fully functional language espe¬ 
cially made for audio signal processing. Faust 
code is compact and elegant, and the compiler 
produces impressively efficient code. It is sim¬ 
ple to compile Faust code into many types of 

1 Note that since inheritance (subclasses) and poly¬ 
morphism (method overloading) are not supported, 
Poing Imperatif should probably not be categorized as 
an OO language. 


formats such as LADSPA plugins, VST plug¬ 
ins, Q, SuperCollider, CSound, PD, Java, Flash, 
LLVM, etc. Faust also offer options to automat¬ 
ically take advantage of multiple processors [Or¬ 
larey et al., 2009; Letz et ah, 2010] and generate 
code which a C++ compiler is able to vectorize 
(i.e. generating SIMD assembler instructions) 
[Scaringella et ah, 2003]. 

1.2 Contributions of Poing Imperatif 

Purely functional programming is unfamiliar 
for many programmers, and translating exist¬ 
ing DSP code written in object oriented or im¬ 
perative style into Faust is not straight forward 
because of different programming paradigms. 

Poing Imperatif can: 

1. Make it easier to start using Faust with¬ 
out having to immediately start thinking 
in fully functional terms. 

2. Make it easier to translate imperative and 
object oriented code to Faust. Porting pro¬ 
grams to Faust makes them: 

(a) Easily available on many different 
platforms and systems. 

(b) Automatically take advantage of mul¬ 
tiple processors. 

(c) Possibly run faster. Faust automati¬ 
cally optimizes code in ways which (i) 
are much hassle to do manually, (ii) 
are hard to think of, or (iii) may have 
been overlooked. 

1.3 Usage 

By default, Poing Imperatif starts the Faust 
compiler automatically on the produced code. 

Any command line option which is unknown to 
Poing Imperatif is sent further to the Faust com¬ 
piler. Example: 

$poing-imperatif -a jack-gtk.cpp -vec freeverb_oo.dsp >freeverb.cpp 

$g++ freeverb.cpp -02 ‘pkg-config —libs —cflags gtk+-2.0‘ -ljack -o freeverb 

$./freeverb 
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Features 

• Setting new values to variables. (I.e. pro¬ 
viding imperative operators such as =, ++, 
+=, etc.) 


4 Example of CH —\- code translated 
to Poing Imperatif 

The CTT implementation of the Freeverb 2 all¬ 
pass filter looks like this: 


• Conditionals, (if /else) 

• Arrays of floats or ints. 

• return operator. 

• Classes, objects, methods and construc¬ 
tors. 

• Optional explicit typing for numeric vari¬ 
ables. Function types are implicitly typed, 
while object types are explicitly typed. The 
void type is untyped. 

• All features of Faust are supported. Faust 
code and Poing Imperatif code can be 
mixed. 


3 Syntax (EBNF) 

class = "class" classname ["(" [var_list] ")"] 

"{" 

{class.elem} 

"}" . 


var_list 

var 

number_type 


= var {"," var} . 

= [number_type] varname . 
= "int" | "float" . 


class_elem 


= array_decl I object_decl I method I statement . 


array_decl 

object_decl 

method 


= number.type arrayname "[" expr "]" ["=" expr] 
= classname objectname ["(" [expr] ")"] . 

= [number.type] methodname "(" [var.list] ")" 
"{" 

{statement} 

"}" . 


expr = faust.expression I inc.assign I dec.assign I class 

I method.call I object_var I array.ref . 

(* Inside classes, faust expressions are extended to expr! *) 


object.var = objectname "." varname . 
array.ref = arrayname "[" expr "]" . 

statement = method.call ";" I block I single.decl 
I if | return I assignment . 


method.call 

block 

single.decl 

if 

return 

assignment 

set.assign 

inc.assign 

dec.assign 

cni.assign 

assign.op 

obvar.set 

array.set 


= objectname "." methodname "(" [expr] ")" . 

= "{" {statement} "}" . 

= number.type name.list ["=" expr] ";" . 

_ ii^fH "(ii ex p r ")" statement ["else" statement] 
= "return" expr ";" . 

= set.assign I inc.assign I dec.assign 
I cni.assign I obvar.set I array.set . 

= name.list "=" expr ";" . 

= name "+" "+" ";" I "+" "+" name ";" 

= name "-" "-" ";" | "-" "-" name ";" 

= name assign.op "=" expr ";" . 

= "+" | | "*•■ | "/" . 

= objectname "." varname "=" expr ";" . 

= arrayname "[" expr "]" "=" expr ";" . 


classname = name 
varname = name 
arrayname = name 
objectname = name 
methodname = name 


name.list = name {"," name} . 

name = alpha, {alpha I digit I "_"} . 


class Allpass{ 
float feedback; 
int bufsize; 
int bufidx; 

float *buffer; 

Allpass(float bufsize,float feedback){ 
this.bufsize = bufsize; 
this.feedback = feedback; 
buffer=calloc(sizeof(float),bufsize); 

> 

> 

float Allpass::process(float input){ 
float bufout = buffer[bufidx]; 

float output = -input + bufout; 
buffer[bufidx] = input + (bufout*feedback); 
if(++bufidx>=bufsize) 
bufidx = 0; 
return output; 


A semi-automatic translation to Poing 
Imperatif yields: 


class Allpass(int bufsize,float feedback){ 
float buffer[bufsize]; 
int bufidx; 
process(float input){ 

float bufout = buffer[bufidx]; 
float output = -input + bufout; 
buffer [bufidx] = input + (bufout*feedback); 
if(++bufidx>=bufsize) 
bufidx = 0; 
return output; 

> 

>; 

5 Constructor 

In the Allpass example above, the Poing 
Imperatif class had a slightly different form than 
the CTT version since a constructor was not 
needed. 

For classes requiring a constructor, impera¬ 
tive code can be placed directly in the class 
block. A class describing a bank account giv¬ 
ing 50 extra euros to all to new accounts, can 
be written like this: 


class Account(int euros){ 

euros += 50; // Constructor! 

debit(int amount){ 
euros -= amount; 

> 

deposit(int amount){ 
euros += amount; 

> 

> 

2 Freeverb is a popular reverb algorithm made by 
“Jezar at Dreampoint”. See Julius O. Smith’s Free¬ 
verb page for more information about it: https:// 
ccrma.Stanford.edu/~jos/pasp/Freeverb.html (The 
web page is from his book “Spectral Audio Signal Pro¬ 
cessing”.) 




6 Accessing a Poing Imperatif class 
from Faust 

The process method is used to bridge Poing 
Imperatif and Faust. If a class has a method 
called process, and that process method contains 
at least one return statement, Poing Imperatif 
creates a Faust function with the same name as 
the class. We call this function the class entry 
function. 

The arguments for the class entry function 
is created from the class arguments and the 
process method arguments. 

=>• For instance, the entry function for this class: 

class Vol(float volume){ 
process (float input)-[ 
return input*volume; 

> 

> 

...looks like this: 

Vol(volume,input) = input*volume; 

...and it can be used like this: 

half.volume = Vol(0.5); 

process(input) = half.volume(input); 

6.1 Recursive variables 

In case the class has variables which could 
change state between calls to the class entry 
function, we use the recursive operator (~) to 
store the state of those variables. 

=>• For instance, this class: 

class Accumulator^ 
int sum; 

process(int inc){ 
sum += inc; 
return sum; 

> 

> 

...is transformed into the following Faust code: 3 

Accumulator(inc) = (funcO ~ (_,_)) : retfuncO with{ 
func0(sum,not.used) = (sum+inc, inc); // sum += inc; 
retfuncO(sum,inc) = sum; // return sum; 

>; 

6.2 Constructors in the class entry 
function 

In case a class contains constructor code or nu¬ 
meric values initialized to a different value than 
0 or 0.0, an additional state variable is used to 
keep track of whether the function is called for 
the first time. In case this additional state vari¬ 
able has the value 0 (i.e. it is the first first time 
the class entry function is called), a special con¬ 
structor function is called first to initialize those 
state variables. 

Simplified for clarity. 


7 Conversion from Poing Imperatif 
to Faust 

7.1 Setting values of variables 

Faust is a purely functional languages. It is not 
possible to give a variable a new value after the 
initial assignment, as illustrated by the follow¬ 
ing pseudocode: 

Possible: 

{ 

int a = 5; 
return a 

> 

Impossible: 

{ 

int a = 5; 
a = 6; 
return a; 

> 

One way to circumvent this is to use a new 
variable each time we set new values. For 
instance, adding 1 to a would look like this: 
a 2 = ai + 1. 

However, Poing Imperatif uses a different ap¬ 
proach, which is to make all operations, includ¬ 
ing assignments, into function calls. 

=>■ For example, the following code: 

float a = 1.0, b=0.0; 
a = a + 1.0; 
b = a + 2.3; 


...is transformed into: 

funcO (a,b) = fund (1.0 ,0.0); // a = 1.0, b=0.0 

func2(a,b) = func3(a+1.0, b); // a = a+1.0 

func4(a,b) = func5(a , a+2.3); // b = a+2.3 

7.2 Conditionals 

When every operation is a function call, 
branching is simple to implement. 

=>■ For instance, the following code: 

if(a==0) 
a=l; 
else 
a=2; 

...is transformed into: 

funcl(a) = if(a==0,func2(a),func3(a)); // if(a==0) 

func2(a) = func4(l); // a=l 

func3(a) = func4(l); // a=2 

if is here a Faust macro [Graf, 2010], and it 

is made to supports multiple signals. The if 
macro looks like this: 

if(a,Ckl,k2),Ck3,k4)) = if(a,kl,k3),if(a,k2,k4); 

if(a,k,k) = k; 

if(a,kl,k2) = select2(a,k2,kl); 



7.3 Methods 


...look like this: 


In Poing Imperatif, an object is a list of all 
the variables used in a class (including method 
arguments). Behind the scene, every method 
receives the “this” object (and nothing more). 
Every method also returns the “this” object 
(and nothing more). Naturally, the “this” 
object may be modified during the execution of 
a method. 

=>• For instance, the method add in: 

class Bank-C 
int a; 

add(int how_much)-( 
a += how_much; 

> 

> 

...is transformed into: 

Bank_add(a,how_much) = funcO(a,how_much) with{ 

funcO(a,how_much) = (a+how_much, how_much); // a += how_much 

>; 

If a method takes arguments, the correspond¬ 
ing variable in the “this” object is set automat¬ 
ically by the caller before the method function 
is called. 

7.4 Return 

A special —return function is created for each 
method which calls return. The reason for using 
the __return function to return values, instead 
of for instance using a special variable to hold 
a return value, is because it is possible to re¬ 
turn more than one value (i.e. to return paral¬ 
lel signals). Furthermore, it is probably cleaner 
to use a special —return function than to fig¬ 
ure out how many signals the various methods 
might return 4 and make corresponding logic to 
handle situations that might show up because 
of this. 

The __return function uses an ’n’ argument 
(holding an integer) to denote which of the 
return expressions to return. 

=>■ For instance, the process and process—return 
functions generated from this class: 

class A{ 

process(int selector){ 
if(selector) 
return 2; 
else 

return 3; 

> 

> 

4 It is also quite complicated to figure out how many 
output signals an expression has. See [Orlarey et ah, 
2004 ], 


A_process(selector,n) = funcO(selector,n) with! 

funcO(selector,n) = if(selector,funci(selector,n),func2(selector,n)); 
fund (selector, n) = (selector ,0) ; // First return 
func2(selector,n) = (selector,1); // Second return 

}; 

A_process_return(selector,n) = 

if(n==0, 

2, // Return 2 from the first return 

3); // Return 3 from the second return 

7.5 Arrays 

Faust has a primitive called rwtable which reads 
from and writes to an array. The syntax for 
rwtable looks like this: 

rwtable(size, init, write_index, write_value, read_index); 

Using rwtable to implement imperative ar¬ 
rays is not straight forward. The problem is 
that rwtable does not return a special array 
object. Instead, it returns the numeric value 
stored in the cell pointed to by ’read_index’. 
This means that there is no array object we can 
send around. 

Our solution is to use rwtable only when read¬ 
ing from an array. When we write to an array, 
we store the new value and array position in two 
new variables. 

=h For instance, the body of process in the fol¬ 
lowing class: 

class Array{ 

float buf[1000]=1.0; 
process(int i){ 
float a = buf[i]; 
buf [i] = a+1.0; 

> 

> 

...is transformed into: 

/* float a = buf[i] */ 

funcO(a, i, buf_pos, buf_val) = 

fund(rwtable(1000,1.0,buf_pos,buf_val,i), i, buf_pos, buf_val); 

/* buf[i] = a+1.0 */ 

fund (a, i, buf_pos, buf_val) = 

(a, i, i, a+1.0); 

However, this solution has a limitation: If a 
buffer is written two times in a row, only the 
second writing will have effect. 

It might be possible to use Faust’s foreign 
function mechanism to achieve complete array 
functionality, by implementing arrays directly 
in C. However, this could limit Faust’s and the 
C compilers ability to optimize. It would also 
complicate the compilation process, and limit 
Poing Imperatif to only work with C and C+- (-. 
(i.e. it would not work with Java, LLVM or 
other languages (or other bitcode/binary for¬ 
mats) Faust supports unless we implement ar¬ 
ray interfaces to Faust for those as well.) 



A fairly relevant question is how important 
full array functionality is? Since full array func¬ 
tionality is not needed for any programs writ¬ 
ten for pure Faust, it’s tempting to believe this 
functionality can be skipped.' 5 

8 Performance compared to Faust 

In Poing Imperatif, Freeverb can be imple¬ 
mented like this: 6 

class Allpass(int bufsize, float feedback){ 
int buf idx; 

float buffer[bufsize] ; 
process(input){ 

float bufout = buffer[bufidx] ; 

float output = -input + bufout; 
buffer[bufidx] = input + (bufout*feedback); 
if(++bufidx>=bufsize) 
buf idx = 0; 
return output; 

> 

> 

class Comb(int bufsize, float feedback, float damp){ 
float filterstore; 
int bufidx; 

float buffer[bufsize] ; 
process(input){ 

filterstore = (buffer[bufidx]*(1.0-damp)) + (filterstore*damp); 
float output = input + (filterstore*feedback); 
buf f er[bufidx] = output; 
if(++bufidx>=bufsize) 
buf idx = 0; 
return output; 

> 

> 

class MonoReverb(float fbl, float fb2, float damp, float spread){ 
Allpass allpassl(allpasstuningLl+spread, fb2); 

Allpass allpass2(allpasstuningL2+spread, fb2); 

Allpass allpass3(allpasstuningL3+spread, fb2); 

Allpass allpass4(allpasstuningL4+spread, fb2); 

Comb combi(combtuningLl+spread, fbl, damp); 

Comb comb2(combtuningL2+spread, fbl, damp); 

Comb comb3(combtuningL3+spread, fbl, damp); 

Comb comb4(combtuningL4+spread, fbl, damp); 

Comb comb5(combtuningL5+spread, fbl, damp); 

Comb comb6(combtuningL6+spread, fbl, damp); 

Comb comb7(combtuningL7+spread, fbl, damp); 

Comb comb8(combtuningL8+spread, fbl, damp); 

process(input){ 

return allpassl.process( 

allpass2.process( 
allpass3.process( 
allpass4.process( 

combi.process(input) + 
comb2.process(input) + 
comb3.process(input) + 
comb4.process(input) + 
comb5.process(input) + 
comb6.process(input) + 
comb7.process(input) + 
comb8.process(input) 

) 

) 

) 

); 


5 One situation where it quite undoubtedly would be 
useful to write or read more than once per sample iter¬ 
ation, is for doing resampling. But for resampling, the 
Faust developers are currently working on a implement¬ 
ing a native solution. [Jouvelot and Orlarey, 2009] 

®The values for the constants combtuningLl, comb- 
tuningLS, allpasstuningLl, etc. are defined in the file 
“examples/freeverb.dsp” in the Faust distribution. 


> 

} 

class StereoReverb(float fbl, float fb2, float damp, int spread){ 
MonoReverb rev0(fbl,fb2,damp,0); 

MonoReverb revl(fbl,fb2,damp,spread); 
process(float left, float right){ 
return rev0.process(left+right), 
revl.process(left+right); 

> 

> 

class FxCtrl(float gain, float wet, Fx){ 
process(float left, float right){ 

float fx_left, fx_right = Fx(left*gain, right*gain); 
return left *(1-wet) + fx_left *wet, 
right*(1-wet) + fx_right*wet; 

> 

> 

process = FxCtrl(fixedgain, 
wetSlider, 

StereoReverb(combfeed, 

allpassfeed, 
dampSlider, 
stereospread 

) 

); 

The version of freeverb included with the 
Faust distribution (performing the exact same 
computations) looks like this: 7 

allpass(bufsize, feedback) = 

(_,_ <: (*(feedback),_:+:@(bufsize)), -) ~ _ : (!,_); 

comb(bufsize, feedback, damp) = 

(+:@(bufsize)) “ (*(l-damp) : (+ ~ *(damp)) : *(feedback)); 

monoReverb(fbl, fb2, damp, spread) 

= _ <: comb (combtuningLl+spread, fbl, damp), 

comb(combtuningL2+spread, fbl, damp), 
comb(combtuningL3+spread, fbl, damp), 
comb(combtuningL4+spread, fbl, damp), 
comb(combtuningL5+spread, fbl, damp), 
comb(combtuningL6+spread, fbl, damp), 
comb(combtuningL7+spread, fbl, damp), 
comb(combtuningL8+spread, fbl, damp) 

+> 

allpass (allpasstuningLl+spread, fb2) 

: allpass (allpasstuningL2+spread, fb2) 

: allpass (allpasstuningL3+spread, fb2) 

: allpass (allpasstuningL4+spread, fb2) 

StereoReverb(fbl, fb2, damp, spread) = 

+ <: monoReverb(fbl, fb2, damp, 0), 

monoReverb(fbl, fb2, damp, spread); 

fxctrl(gain,wet,Fx) = 

<: (*(gain),*(gain) : Fx : *(wet),*(wet)), 

*(1-wet),*(1-wet) 

+> 

process = fxctrl(fixedgain, 
wetSlider, 

StereoReverb(combfeed, 

allpassfeed, 

dampSlider, 

stereospread 

) 

); 

Benchmarking these two versions against 
each other showed that the version written for 
pure Faust was approximately 30% faster than 
the version written for Poing Imperatif. 

7 Slightly modified for clarity. 






After inspecting the generated C++ source 
for the Allpass class and the Comb class, it 
seemed like the only reason for the difference 
had to be the use of rwtable to access arrays. 

By changing the Poing Imperatif versions 
of Comb and Allpass to use Faust’s delay 
operator @ instead of rwtable, we get this code: 

class Allpass(int bufsize, float feedback){ 
float bufout; 
process(float input){ 

float output = -input + bufout; 

bufout = input + (bufout*feedback) : Q(bufsize); 

return output; 

> 

> 

class Comb(int bufsize, float feedback, float damp){ 
float filterstore; 
float bufout; 
process(float input){ 

filterstore = (output*(1.0-damp)) + (filterstore*damp); 
bufout = input + (filterstore*feedback) : ©(bufsize); 

return bufout; 

> 

> 

Now the pure Faust version was only 7.5% 
faster than the Poing Imperatif version. This 
result is quite good, but considering that se¬ 
mantically equivalent C++ code were generated 
both for the Comb class and the Allpass class 
(the Allpass class was even syntactically equiv¬ 
alent), 8 plus that optimal Faust code were gen¬ 
erated for the three remaining classes (MonoRe- 
verb, StereoReverb, and FxCtrl), both versions 
should in theory be equally efficient. However, 
after further inspection of the generated C++ 
code, a bug in the optimization part of the 
Faust compiler was revealed. 9 After manually 

8 Semantically equivalent means here that the code 
is equal, except that variable names might differ, inde¬ 
pendent statements could be placed in a different order, 
or that the number of unnecessary temporary variables 
differ. 

9 The decreased performance was caused by two differ¬ 
ent summing orders of the same group of signals (which 
is a bug, order is supposed to be equal). This again 
caused sub-summations not to be shared, probably be¬ 
cause equal order is needed to identify common sub¬ 
expressions. The bug only causes a slight decreased per¬ 
formance in certain situations, it does not change the 
result of the computations. The bug can also be pro¬ 
voked by recoding the definition of allpass in the pure 
Faust version of Freeverb to: 

allpass(bufsize, feedback, input) = (process ~ (_,!)) : (!,_) with{ 
process(bufout) = ( 

(input + (bufout * feedback ): @ (bufsize )), 

(-input + bufout ) 

); 

>; 

...which is just another way to write the same function. 

The bug was reported right before this paper was sub¬ 
mitted, it has been acknowledged, and the problem is 
being looked into. Thanks to Yann Orlarey for a fast 


fixing the two non-optimal lines of C++ code 
caused by this bug in the Faust compiler, both 
versions of Freeverb produce similarly efficient 
code. The final two C++ sources also look se¬ 
mantically equivalent. 

9 Implementation 

The main part of Poing Imperatif is written in 
the Qi language [Tarver, 2008]. Minor parts of 
the source are written in C++ and Common 
Lisp. Poing Imperatif uses Faust’s own lexer. 

The source is released under GPL and can be 
downloaded from: 

http://www.notam02.no/arkiv/src/ 
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